System and Method for Providing Dynamically Variable Maps in a Video Game

ABSTRACT

A system and method for providing dynamically variable maps in a video game is disclosed. A map is provided that defines a playable space available to one or more game players in a video game. Gameplay is monitored in real-time for the detection of a trigger event. Upon detection of a trigger event, a map management engine dynamically modifies a configuration of the map to improve the gameplay experience based on the type of trigger event. Dynamic modification of a map may comprise altering one or more of the map boundary, and/or the location, position, size, number, state, etc. of one or more static map objects or dynamic map objects. As a result of the dynamic modification of the map, the map may transform from its initial (or first or beginning) configuration to a modified (or new or second) configuration.

CROSS REFERENCE

The present application is a division application of U.S. patentapplication Ser. No. 16/601,264, entitled “System and Method forProviding Dynamically Variable Maps in a Video Game” and filed on Oct.14, 2019, which is a division application of U.S. patent applicationSer. No. 14/712,417, of the same title, filed on May 14, 2015, andissued as U.S. Pat. No. 10,486,068 on Nov. 26, 2019, both of which areherein incorporated by reference in their entirety.

FIELD OF THE INVENTION

The invention relates generally to video games, and more particularly toa system and method for providing dynamically variable maps in a videogame.

BACKGROUND OF THE INVENTION

In most video games, a map is provided that defines the playable spaceavailable to one or more game players. A map may also be referred to as,for example, an area, a stage, a world, a zone, a location, or anothersimilar descriptor. While the particular nature of a map may depend onthe type of video game, some non-limiting examples of maps may include abuilding layout (e.g., one or more floors), a city layout, a forest, afort, a battlefield, a racetrack, etc. Numerous other examples exist.

In those instances where the same map(s) are played repeatedly in avideo game without variety or the introduction of new maps, game playersmay grow tired of playing the video game after a short period of time.

A lack of maps, or a lack of variety in the maps provided, may result inadditional drawbacks for multiplayer video games in which two or moreplayers typically play in a match during a gameplay session in acooperative or adversarial relationship. One disadvantage of havingfewer maps in a multiplayer game (in addition to boredom), is that anappropriate-sized map may not be available for every possible number ofplayers. For instance, a map of a larger scale that is designed (oroptimal) for twenty total players in a gameplay session may be too largeor challenging (and therefore unsatisfying) for two teams of two playerseach (four total players). Likewise, a smaller scale map that isdesigned (or optimal) for eight total players in a gameplay session maybe too constrained for two teams of ten players (twenty total players).In either instance, the enjoyment of gameplay may be diminished,resulting in frustrated or discouraged players.

Another example of a drawback associated with a limited number orvariety of maps in a multiplayer game is that veteran players maydevelop more familiarity with available map(s), and hence an unbalancedadvantage, over newer players. As such, novice or lower-skilled players,for instance, may feel that they are continually at a disadvantage.

Currently, a “brute force” approach exists to providing game playerswith more map variety, which is to generate more maps. One disadvantageof this approach is the time and expense required for video gamedevelopers to create entirely new maps. Creating new maps may require,among other things, a formidable amount of development time that maynegatively impact a developer's ability to provide additional contentand/or new titles to consumers. In addition, the new maps must bedelivered to the game players' systems, adding additional costs andresources.

Another approach to providing map variety is to limit the availabilityof certain maps to gamers to pre-announced times. For example, a mapwhich might normally be disabled during peak multiplayer gameplay hoursmay be made available to players at a time when player counts mightotherwise be low. This approach, however, also provides disadvantages.For instance, the map that is made available is still a separate mapthat requires time and expense to create. Further, having a given mapavailable for a limited time period still requires players to play theother available maps in a frequent manner until the pre-announced times,which may result in a poor or unsatisfying player experience.

These and other drawbacks exist with current maps in video games.

SUMMARY OF THE INVENTION

The invention addressing these and other drawbacks relates to a systemand method for providing dynamically variable maps in a video game.

A dynamically variable (or modifiable) map is a map that defines aplayable space available to one or more game players in a video game,and that may be altered from an initial (or first) configuration to amodified (or second) configuration, and so on, during a gameplay sessionto thereby change the playable space available to the players. In thedescription that follows, for brevity, the term “map” may be used inlieu of “dynamically variable map.”

According to an aspect of the invention, a map may comprise one or moremap features (or attributes) including, for example, a map boundary (orperimeter), one or more static map objects, and one or more dynamic mapobjects.

A map boundary may define (in whole or in part) an area of playablespace available to one or more game players during a gameplay session.As described herein, the map boundary may be scalable (e.g., may expandor contract) or be otherwise altered during a gameplay session to changethe area of available playable space.

Static map objects comprise objects that are typically stationary andmay include, without limitation, objects such as a building, a wall,furniture, a tree, a large boulder, a body of water, a mountain, etc.The type of static map objects that may be presented on a map may differdepending on the type of video game.

Dynamic map objects are objects that may be movable from one position toanother, or from one state to another. For instance, a vehicle maycomprise a dynamic map object, as may a door or drawbridge that iscapable of being moved from an open position (or state) to a closedposition (or state). Similar to static map objects, the type of dynamicmap objects that may be presented on a map may differ depending on thetype of video game. In some instances, a dynamic map object may be movedor manipulated to change the area of (or otherwise alter aspects of) theavailable playable space.

In certain implementations, some static map objects may be considereddynamic map objects if they are capable of being (or are) moved ormanipulated during gameplay. For example, a large boulder may comprise astatic map object. However, the large boulder may also be considered adynamic map object if it is capable of being (or is) moved ormanipulated by one or more characters or equipment during a gameplaysession.

According to an aspect of the invention, various configurations ofplayable space of a single map may be obtained by dynamically modifyingthe map boundary, one or more static map objects, and/or one or moredynamic map objects during a gameplay session. More particularly, a mapmay transform from an initial (or first) configuration to a modified (orsecond) configuration, and so on, during a gameplay session by alteringthe map boundary, and/or the location, position, size, number, state,etc. of one or more of static map objects, and/or dynamic map objectsbased on trigger events that occur during gameplay.

Examples of trigger events may include, but are not limited to, a changein a number of players in the gameplay session (e.g., the number ofplayers exceeds or falls below a predetermined threshold), a change in anumber of game players playing a particular player role (e.g., a numberof a certain type of player roles in a match exceeds or falls below apredetermined threshold), the pace or frequency of gameplayactions/events exceeding or falling below a predetermined threshold, thecommencement of a competition or newly available mission that takesplace in a map, an inference that one or more players are unhappy withthe current configuration of a map or otherwise would prefer variety(e.g., by monitoring unexpected attrition/rage quitting, or throughexplicit in-game voting or other feedback), or a change in othergameplay information, among other examples.

Trigger events may be system-defined (e.g., defined by the game logic)or user-defined (e.g., through one or more user interfaces prior to thecommencement of a gameplay session). It should be appreciated thattrigger events may be different for different maps, different videogames, and/or for different maps utilized in the same video game. Insome implementations, a collection of defined trigger events may beaccessed and selectively applied to individual maps. In otherimplementations, trigger events may be created or customized forparticular maps.

According to an aspect of the invention, a matchmaking engine mayidentify one or more players that are waiting to be matched (grouped),such as players whose in-game avatars are waiting in a virtual gamelobby to join a gameplay session. The gameplay session may comprise anytype of gameplay session including, without limitation, a real gameplaysession and/or a practice gameplay session (e.g., associated with a“practice” or “training” mode of a game).

In one implementation, a player may be added to a gameplay sessionimmediately if there is an opening. In another implementation, one ormore gameplay sessions may be dynamically combined to create a singlegameplay session involving the aggregate of all players in each of theoriginal gameplay sessions. A gameplay session may be dynamically splitto create two or more gameplay sessions, where a matchmaking engine maydetermine which players from the original sessions are grouped andplaced into the resulting two or more gameplay sessions.

In one implementation, the matchmaking engine may generate one or morematches by grouping two or more of the identified players. The number ofplayers placed in each match (contest) may depend on a number of playerswaiting to be matched, a number of players needed for a game session(e.g., a number of players needed to form a team or start a match), anumber of players that can be accommodated by a game session, and/orother information. Different matches may include different combinationsof different players, which may include different numbers of players.

The matchmaking engine may use known or hereafter-developed matchmakingtechniques to generate a match by grouping players in an effort toproduce the most satisfying player experiences. Game profiles, playerprofiles, match variables, and other factors may be considered whengenerating matches.

For clarity, it should be appreciated that the process of “matching”players refers to the grouping of players, and that “matched” playerscomprise players that have been grouped together (either in acooperative or adversarial relationship) for a gameplay session by, forexample, the matchmaking engine. Further, a “match” may also refer to acontest that is the subject of a gameplay session.

According to an aspect of the invention, a map selection engine mayselect, generate, or otherwise obtain a map for a match of a gameplaysession. In some implementations, the map selection engine may selectand retrieve one or more maps from among a collection of pre-generatedmaps stored, for instance, in one or more databases. Alternatively, themap selection engine may generate one or more maps, or dynamicallymodify one or more existing maps, in real-time (“on the fly”) for agameplay session to change the playable space by altering one or more ofthe map's boundary, static map object(s), and/or dynamic map object(s).

In some implementations, a map (whether selected, generated, ormodified) may have an initial (or first or beginning) configurationbased on gameplay session information. Gameplay session information maydescribe various game characteristics of a gameplay session that mayinfluence the quality of gameplay. For example, gameplay sessioninformation may include, without limitation, a number of players, acomposition of teams (e.g., number and/or types of roles in each team),duration of gameplay (e.g., how long a given gameplay session isexpected to last), types of matches (e.g., team death match, capture theflag, etc.), and/or other information related to a gameplay session. Inanother implementation, a map may be selected for a match randomly.

In other implementations, one or more players may select the map to beplayed in a match of the gameplay session. For instance, before thestart of a match, one or more players may vote on the map to be usedduring the gameplay session.

According to an aspect of the invention, once one or more players havebeen matched, and a map has been selected, generated, and/or modified, agameplay session may commence. Gameplay may be monitored in real-timefor the detection of a trigger event (e.g., by a trigger detectionengine, or other game logic).

According to an aspect of the invention, when a trigger event isdetected during gameplay, a map may be dynamically modified (from itsinitial configuration) as described in detail below. In someimplementations, depending on the type of trigger event, detection ofthe trigger event alone may be sufficient to dynamically modify the map.In other implementations, the gameplay event or action that produced (orresulted in) the triggering event must persist for a predeterminedperiod of time (e.g., a modification waiting period) before the map isdynamically modified. This avoids changing the map frequently when neartrigger thresholds, since players may find this confusing or disruptivedepending on the game or map design.

In some instances, two or more trigger events may occur during gameplay(and be detected) at substantially the same time. For example, both anumber of players and a number of player roles of a certain type mayexceed a predetermined threshold at substantially the same time. In suchan instance, either or both of the detected trigger events may result ina dynamic modification of the map. For example, in one implementation,the most significant trigger event, as defined by game logic or a user,may be used to dynamically modify a configuration of the map.Alternatively, each trigger event may be used to dynamically modify aconfiguration of the map. In some implementations, the occurrence ofmultiple trigger events may reduce the waiting period to dynamicallymodify the map. For example, if one or more additional trigger eventsoccur during the modification waiting period, the modification waitingperiod may be truncated. In other implementations, if two or moresignificant trigger events are detected within a predetermined (e.g.,short) period of time, the dynamic map modification may occurimmediately without a modification waiting period. Other configurationsmay be implemented.

In one implementation, a map management engine may dynamically modify aconfiguration of the map to improve the gameplay experience based on thetype of trigger event. Dynamic modification of a map may comprise anyone or more of: altering the boundary (or perimeter) of the map by, forexample, increasing or decreasing the boundary such that the boundaryrespectively defines a larger or smaller area of playable space, and/oropening up or closing (or otherwise altering) one or more portions ofthe boundary; altering the location, position, size, number, state, etc.of one or more static map objects on the map; altering the location,position, size, number, state, etc. of one or more dynamic map objectson the map; scaling the entire map by increasing or decreasing the sizeof the map and its constituent objects (including any static mapobjects, dynamic map objects, virtual characters or avatars depictingplayers, etc.) to increase or decrease the area of available space,respectively; adding or removing non-player characters (NPC) or otherartificial intelligence (AI) controlled avatars to the gameplayexperience; combining all or a portion of the map with all or a portionof one or more additional maps; and/or modifying the attributes ofexisting map objects or terrain such that player interaction isfundamentally impacted. As a result of the dynamic modification of themap, the map may transform from its initial (or first or beginning)configuration to a modified (or new or second) configuration.

The following are illustrative and non-limiting examples of the variousways in which a map may be dynamically modified in real-time duringgameplay in response to certain trigger events. While the examplesdescribed herein may reference various game levels or modes, characters,roles, game items, etc. associated with a First-Person-Shooter (FPS)game, it should be appreciated that any such examples are forillustrative purposes only, and are not intended to be limiting. Thesystem and method described in detail herein may be used in any genre ofmultiplayer video game, without limitation.

In one implementation, a map be dynamically modified in real-time,during gameplay, based on a trigger event associated with a change in anumber of players in the gameplay session (e.g., the number of playersexceeds or falls below a predetermined threshold).

As one example, if a number of players during a gameplay session fallsbelow a predetermined number (e.g., a lower or first threshold), the mapmanagement engine may switch the state of one or more dynamic mapobjects (e.g., close a doorway, block a hallway, remove a bridge, etc.)of the map to selectively close off regions of the map, therebydecreasing the available playable space of the map. In this regard, theremaining players may be forced to play in a smaller area which may,depending on the nature of the game, increase encounters with otherplayers to foster more exciting action and gameplay. In someimplementations, when a region of a map is selectively closed off (orotherwise dynamically altered), player avatars may be transported out ofthe non-playable area to another area of the map (e.g., to a standardsafe spawn site). Alternatively, player avatars may be spawned elsewhereafter a death (or other game event), and the region of the map to beclosed may be closed once no more player avatars are in the region.

Conversely, if a number of players during a gameplay session exceeds apredetermined number (e.g., a higher or second threshold number), themap management engine may switch the state of one or more dynamic mapobjects (e.g., open a doorway, unblock a hallway, add/open a bridge,etc.) of the map to selectively open up additional regions of the map,thereby increasing the available playable space of the map.

In one implementation, a map may be dynamically modified in real-time,during gameplay, based on a trigger event associated with a change in anumber of game players playing a particular player role. Player rolesmay, of course, differ based on the particular video game.

As a non-limiting example, a player role in a First-Person-Shooter gamemay comprise that of a sniper. During a gameplay session, if a number ofplayers in the sniper role decreases to a number equal to or below afirst (or lower) pre-determined threshold number, the map managementengine may, as a result of the triggering event, add or provide laddersto (newly added or existing) sniper perches to the map or improvelong-distance sight lines by removing occluding objects in order toincentivize players to switch to a sniper role to provide more balancedgameplay. In another example, the map may shrink or remove variousmap-based sniper advantages based on the inference that current playersfavor close-quarters gameplay.

By contrast, if a number of players in the sniper role increases duringa gameplay session to a number equal to or above a second (or higher)pre-determined threshold number, the map management engine may, as aresult of the triggering event, remove ladders and/or remove sniperperches and/or add occluding objects which reduce sight lines from themap in order to deter players from selecting the sniper role.

The types of static and/or dynamic map objects that may be added to orremoved from (or be otherwise altered on) a map may differ based on thetype and nature of various player roles in various video games.

In one implementation, a map may be dynamically modified in real-time,during gameplay, based on a trigger event associated with the pace orfrequency of certain gameplay actions or events.

Referring once again to the example of a First-Person-Shooter game,excitement during gameplay may, for example, be based on the frequencyof the occurrence of a particular event such as a firefight. As such,during a gameplay session, if the frequency of firefights decreases to avalue equal to or below a first (or lower) pre-determined thresholdvalue, the map management engine may, as a result of the triggeringevent, alter the area of playable space on the map by altering one ormore of the map's boundary, static map object(s), and/or dynamic mapobject(s) to provide more opportunities for firefights and increase thepace of play.

By contrast, if the frequency of firefights increases during a gameplaysession to a value equal to or above a second (or upper) pre-determinedthreshold value, the map management engine may, as a result of thetriggering event, alter the area of playable space on the map byaltering one or more of the map's boundary, static map object(s), and/ordynamic map object(s) to reduce the number of firefights and slow downthe pace of play.

The various types of game actions or events that may be used as atriggering event may, of course, differ based on the particular videogame.

In addition to the foregoing examples, a map may be dynamically modifiedin real-time, during gameplay, based on a trigger event associated withchanges in other gameplay state information including, withoutlimitation, types of matches (e.g., team death match, capture the flag,etc.), elapsed time or remaining time in a gameplay session, and/orother information related to a gameplay session.

These and other objects, features, and characteristics of the systemand/or method disclosed herein, as well as the methods of operation andfunctions of the related objects of structure and the combination ofparts and economies of manufacture, will become more apparent uponconsideration of the following description and the appended claims withreference to the accompanying drawings, all of which form a part of thisspecification, wherein like reference numerals designate correspondingparts in the various figures. It is to be expressly understood, however,that the drawings are for the purpose of illustration and descriptiononly and are not intended as a definition of the limits of theinvention. As used in the specification and in the claims, the singularform of “a”, “an”, and “the” include plural referents unless the contextclearly dictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an exemplary system for providing dynamicallyvariable maps in a video game, according to an aspect of the invention.

FIG. 1B illustrates an exemplary system for providing dynamicallyvariable maps in a video game, according to an aspect of the invention.

FIG. 2A illustrates an exemplary system configuration in which a serverhosts a plurality of computer devices to facilitate a multiplayer game,according to an aspect of the invention.

FIG. 2B illustrates an exemplary system configuration in which aplurality of networked servers communicate with one another tofacilitate a multiplayer game, according to an aspect of the invention.

FIG. 2C illustrates an exemplary system configuration in which aplurality of computer devices are networked together to facilitate amultiplayer game, according to an aspect of the invention.

FIG. 3 depicts an exemplary illustration of a map that may be utilizedin a gameplay session, according to an aspect of the invention.

FIGS. 4A-4C illustrate exemplary configurations of a map that may beutilized in a gameplay session, according to an aspect of the invention.

FIG. 5 depicts an exemplary flowchart of processing operations forproviding dynamically variable maps in a video game, according to anaspect of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The invention described herein relates to a system and method forproviding dynamically variable maps in a video game.

Exemplary System Architecture

FIGS. 1A and 1B each depict an exemplary architecture of a system 100which may include one or more computer systems 110, one or more servers150, one or more databases 160, and/or other components, according toone implementation of the invention.

FIG. 1A illustrates an implementation in which server(s) 150 function asa host computer that hosts gameplay between other devices, such ascomputer system(s) 110.

FIG. 1B illustrates an implementation in which a given computer system110 functions as a host computer that hosts gameplay between (or with)other devices, such as other computer system(s) 110. Unless specificallystated otherwise, the description of various system components may referto either or both of FIGS. 1A and 1B.

Computer System 110

Computer system 110 may be configured as a gaming console, a handheldgaming device, a personal computer (e.g., a desktop computer, a laptopcomputer, etc.), a smartphone, a tablet computing device, and/or otherdevice that can be used to interact with an instance of a video game.

Referring to FIG. 1B, computer system 110 may include one or moreprocessors 112 (also interchangeably referred to herein as processors112, processor(s) 112, or processor 112 for convenience), one or morestorage devices 114 (which may store a map management application 120),one or more peripherals 140, and/or other components. Processors 112 maybe programmed by one or more computer program instructions. For example,processors 112 may be programmed by map management application 120and/or other instructions (such as gaming instructions used toinstantiate the game).

Depending on the system configuration, map management application 120(or portions thereof) may be part of a game application, which creates agame instance to facilitate gameplay. Alternatively or additionally, mapmanagement application 120 may run on a device such as a server 150.

Map management application 120 may include instructions that programcomputer system 110. The instructions may include, without limitation, amatchmaking engine 122, a map selection engine 124, a trigger detectionengine 128, a map management engine 130, and/or other instructions 132that program computer system 110 to perform various operations, each ofwhich are described in greater detail herein. As used herein, forconvenience, the various instructions will be described as performing anoperation, when, in fact, the various instructions program theprocessors 112 (and therefore computer system 110) to perform theoperation.

Peripherals 140

Peripherals 140 may be used to obtain an input (e.g., direct input,measured input, etc.) from a player. Peripherals 140 may include,without limitation, a game controller, a gamepad, a keyboard, a mouse,an imaging device such as a camera, a motion sensing device, a lightsensor, a biometric sensor, and/or other peripheral device that canobtain an input from a player. Peripherals 140 may be coupled to acorresponding computer system 110 via a wired and/or wirelessconnection.

Server 150

Server 150 may include one or more computing devices.

Referring to FIG. 1A, server 150 may include one or more physicalprocessors 152 (also interchangeably referred to herein as processors152, processor(s) 152, or processor 152 for convenience) programmed bycomputer program instructions, one or more storage devices 154 (whichmay store a map management application 120), and/or other components.Processors 152 may be programmed by one or more computer programinstructions. For example, processors 152 may be programmed by gaminginstructions used to instantiate the game.

Depending on the system configuration, map management application 120(or portions thereof) may be part of a game application, which creates agame instance to facilitate gameplay. Alternatively or additionally,portions or all of map management application 120 may run on computersystem 110 or server 150.

Map management application 120 may include instructions that programserver 150. The instructions may include, without limitation, amatchmaking engine 122, a map selection engine 124, a trigger detectionengine 128, a map management engine 130, and/or other instructions 132that program server 150 to perform various operations, each of which aredescribed in greater detail herein. As used herein, for convenience, thevarious instructions will be described as performing an operation, when,in fact, the various instructions program the processors 152 (andtherefore server 150) to perform the operation.

Although each is illustrated in FIGS. 1A and 1B as a single component,computer system 110 and server 150 may each include a plurality ofindividual components (e.g., computer devices) each programmed with atleast some of the functions described herein. In this manner, somecomponents of computer system 110 and/or server 150 may perform somefunctions while other components may perform other functions, as wouldbe appreciated. Thus, either or both server 150 and computer system 100may function as a host computer programmed by map management application120. The one or more processors (112, 152) may each include one or morephysical processors that are programmed by computer programinstructions. The various instructions described herein are exemplaryonly. Other configurations and numbers of instructions may be used, solong as the processor(s) (112, 152) are programmed to perform thefunctions described herein.

Furthermore, it should be appreciated that although the variousinstructions are illustrated in FIG. 1 as being co-located within asingle processing unit, in implementations in which processor(s) (112,152) includes multiple processing units, one or more instructions may beexecuted remotely from the other instructions.

The description of the functionality provided by the differentinstructions described herein is for illustrative purposes, and is notintended to be limiting, as any of instructions may provide more or lessfunctionality than is described. For example, one or more of theinstructions may be eliminated, and some or all of its functionality maybe provided by other ones of the instructions. As another example,processor(s) (112, 152) may be programmed by one or more additionalinstructions that may perform some or all of the functionalityattributed herein to one of the instructions.

Storage Devices 114

The various instructions described herein may be stored in one or morestorage devices, such as storage device (114, 154), which may compriserandom access memory (RAM), read only memory (ROM), and/or other memory.The storage device may store the computer program instructions (e.g.,the aforementioned instructions) to be executed by processor (112, 152)as well as data that may be manipulated by processor (112, 152). Thestorage device may comprise floppy disks, hard disks, optical disks,tapes, or other storage media for storing computer-executableinstructions and/or data.

Network 102

The various components illustrated in FIG. 1 may be coupled to at leastone other component via a network 102, which may include any one or moreof, for instance, the Internet, an intranet, a PAN (Personal AreaNetwork), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN(Storage Area Network), a MAN (Metropolitan Area Network), a wirelessnetwork, a cellular communications network, a Public Switched TelephoneNetwork, and/or other network.

In FIG. 1, as well as in other drawing Figures, different numbers ofentities than those depicted may be used. Furthermore, according tovarious implementations, the components described herein may beimplemented in hardware and/or software that configure hardware.

Databases 160

The various databases 160 described herein may be, include, or interfaceto, for example, an Oracle™ relational database sold commercially byOracle Corporation. Other databases, such as Informix™, DB2 (Database 2)or other data storage, including file-based, or query formats,platforms, or resources such as OLAP (On Line Analytical Processing),SQL (Structured Query Language), a SAN (storage area network), MicrosoftAccess™ or others may also be used, incorporated, or accessed. Thedatabase may comprise one or more such databases that reside in one ormore physical devices and in one or more physical locations. Thedatabase may store a plurality of types of data and/or files andassociated data or file descriptions, administrative information, or anyother data.

The foregoing system architecture is exemplary only and should not beviewed as limiting. Other system configurations may be used as well, aswould be appreciated by those having skill in the art.

Exemplary Multiplayer System Configurations

As noted above, a multiplayer video game is a video game in which two ormore players play in a gameplay session in a cooperative or adversarialrelationship. Multiplayer video games have exploded in popularity due,in part, to services such as Microsoft's Xbox LIVE® and Sony'sPlayStation Network® which enable gamers all over the world to play withor against one another. Typically, when a player logs in to a gamesystem or platform to play a multiplayer video game, the player mayengage in a gameplay session in which he or she is matched with otherplayers to play together (on the same team or as opponents).

FIG. 2A illustrates an exemplary system configuration 200A in which aserver hosts a plurality of computer devices to facilitate a multiplayergame, according to an implementation of the invention. In oneimplementation, one or more servers 150 may host a number of computersystems 110 (illustrated as computer systems 110A, 110B, . . . , 110N)via network 102. Each computer system 110 may include one or moreperipherals (illustrated as peripherals 140A, 140B, . . . , 140N). Inthis manner, one or more servers 150 may facilitate the gameplay ofdifferent players using different computer systems 110 and/or otherwiseprovide one or more operations of map management application 120(illustrated in FIG. 1).

In some instances, a given server 150 may be associated with aproprietary gameplay network system, such as, without limitation,Microsoft's Xbox LIVE® and Sony's PlayStation Network®, and/or anothertype of gameplay network system. In this implementation, a givencomputer system 110 may be associated with a particular type of gamingconsole. Other types of computer systems 110 using other types ofgameplay networks may be used as well.

FIG. 2B illustrates an exemplary system configuration 200B in which aplurality of computer systems 110 are networked together to facilitate amultiplayer game, according to an implementation of the invention. Anyone or more of the computer devices 110 may serve as a host and/orotherwise provide one or more operations of map management application120 (illustrated in FIG. 1).

FIG. 2C illustrates an exemplary system configuration 200C in which acomputer system 110 is used by a plurality of users to facilitate amultiplayer game, according to an implementation of the invention. In animplementation, computer system 110 may be considered to host themultiplayer game and/or otherwise provide one or more operations of mapmanagement application 120 (illustrated in FIG. 1).

Referring to FIGS. 2A-2C, in an implementation, a host may facilitatethe multiplayer game and/or perform other operations described herein.In an implementation, at least some of these operations may also orinstead be performed by an individual computer system 110. Furthermore,the illustrated system configurations are exemplary only and should notbe viewed as limiting in any way. Other system configurations may beused as well, as would be appreciated by those having skill in the art.

While aspects of the invention may be described with reference tomultiplayer video games, it should be recognized that the features andfunctionality described herein are equally applicable to a single playervideo game.

Generating Matches

According to an aspect of the invention, matchmaking engine 122 mayidentify one or more players that are waiting to be matched, such asplayers whose in-game avatars are waiting in a virtual game lobby tojoin a gameplay session. The gameplay session may comprise any type ofgameplay session including, without limitation, a real gameplay sessionand/or a practice gameplay session (e.g., associated with a “practice”or “training” mode of a game).

In one implementation, a player may be added to a gameplay sessionimmediately if there is an opening. In another implementation, one ormore gameplay sessions may be dynamically combined to create a singlegameplay session involving the aggregate of all players in each of theoriginal gameplay sessions. A gameplay session may be dynamically splitto create two or more gameplay sessions, where a matchmaking engine maydetermine which players from the original sessions are grouped andplaced into the resulting two or more gameplay sessions.

In one implementation, matchmaking engine 122 may generate one or morematches by grouping two or more of the identified players. The number ofplayers placed in each match may depend on a number of players waitingto be matched, a number of players needed for a game session (e.g., anumber of players needed to form a team or start a match), a number ofplayers that can be accommodated by a game session, and/or otherinformation. Different matches may include different combinations ofdifferent players, which may include different numbers of players.

Matchmaking engine 122 may use known or hereafter-developed matchmakingtechniques to generate a match (e.g., interchangeably referred to hereinas “matchmaking”) by grouping players in an effort to produce the mostsatisfying player experiences. Game profiles, player profiles, matchvariables, and other factors may be considered when generating matches.

Exemplary Map

According to one implementation of the invention, map selection engine124 may select, generate, or otherwise obtain a map for a match of agameplay session. FIG. 3 depicts an exemplary illustration of a map 300that may be utilized in a gameplay session. Map 300 may comprise one ormore map features (or attributes) including, for example, a map boundary(or perimeter) 304, one or more static map objects 306, and one or moredynamic map objects 308.

Map boundary 304 may define (in whole or in part) an area of playablespace 302 available to one or more game players during a gameplaysession. As described in greater detail below, map boundary 304 may bescalable (e.g., may expand or contract) or be otherwise altered during agameplay session to change the area of playable space 302.

Examples of static map objects 306 may include, without limitation,objects that are typically stationary such as a building, a wall,furniture, a tree, a large boulder, a body of water, a mountain, etc.The type of static map objects 306 presented on map 300 may of coursediffer depending on the type of video game.

Dynamic map objects 308 are objects that may be movable from oneposition to another, or from one state to another. For instance, avehicle (e.g., a race car, truck, spaceship, etc.) may comprise adynamic map object 308. A door or drawbridge that is capable of beingmoved from an open position (or state) to a closed position (or state),or a river whose water level changes to make it passable or impassable,etc. may also comprise a dynamic map object 308. The type of dynamic mapobjects 308 presented on map 300 may differ depending on the type ofvideo game. In some instances, a dynamic map object may be moved ormanipulated to change the area of (or otherwise alter aspects of)playable space 302 (as described in greater detail below).

In certain implementations, some static map objects 306 may beconsidered dynamic map objects if they are capable of being (or are)moved or manipulated during gameplay. For example, a large boulder maycomprise a static map object 306. However, the large boulder may also beconsidered a dynamic map object 308 if it is capable of being (or is)moved or manipulated by one or more characters or equipment during agameplay session.

According to an aspect of the invention, one or more of boundary 304,static map object(s) 306, and/or dynamic map object(s) 308 maycollectively comprise a configuration of playable space 302 available toplayers during a gameplay session. The configuration of availableplayable space 302 may therefore be altered during a gameplay session bychanges to boundary 304, and/or the location, position, size, number,state, etc. of one or more of static map object(s) 306, and/or dynamicmap object(s) 308.

As one non-limiting example, map 300 may comprise one or more regions310 (e.g., region A, region B, region C, etc.). Map 300 may comprise afloor plan of a building, regions A-C may comprise separate rooms,dynamic map objects 308 may comprise doors, and static map objects 306may comprise pieces of furniture. The total area of playable space 302may comprise rooms A, B, and C if all of doors 308 are open, or areunlocked and capable of being opened. By contrast, doors 308 may belocked between rooms A and B, or rooms B and C. Accordingly, floor plan300 may be dynamically configured or modified such that total area ofplayable space 302 comprises room A, room B, room C, rooms A and B,rooms B and C, or rooms A, B, and C. As yet another example, one or morepieces of furniture (or static map objects) 306 may be moved into aposition to block an open door 308 such that the same effect is achievedas if door 308 were closed or locked.

As the foregoing clearly demonstrates, various configurations ofplayable space 302 may be achieved by dynamically modifying a single map300.

In one implementation, as described in greater detail below, theconfiguration of the playable space 302 may be altered during a gameplaysession by changes to boundary 304, and/or the location, position, size,number, state, etc. of one or more of static map object(s) 306, and/ordynamic map object(s) 308 based on trigger events that occur duringgameplay.

Map Selection or Generation—Initial Configuration

As noted above, map selection engine 124 may select, generate, orotherwise obtain a map for a match of a gameplay session. For example,in some implementations, map selection engine 124 may select andretrieve one or more maps from among a collection of pre-generated mapsstored, for instance, in database 160. Alternatively, map selectionengine 124 may generate one or more maps, or dynamically modify one ormore existing maps, in real-time (“on the fly”) for a gameplay sessionto change the playable space by altering one or more of the map'sboundary, static map object(s), and/or dynamic map object(s), asdescribed above.

In some implementations, a map (whether selected, generated, ormodified) may have an initial (or first or beginning) configurationbased on gameplay session information. Gameplay session information maydescribe various game characteristics of a gameplay session that mayinfluence the quality of gameplay. For example, gameplay sessioninformation may include, without limitation, a number of players, acomposition of teams (e.g., number and/or types of roles in each team),duration of gameplay (e.g., how long a given gameplay session isexpected to last), types of matches (e.g., team death match, capture theflag, etc.), and/or other information related to a gameplay session. Inanother implementation, a map may be selected for a match randomly.

In other implementations, one or more players may select the map to beplayed in a match of the gameplay session. For instance, before thestart of a match, one or more players may vote on the map to be usedduring the gameplay session.

Trigger Events & Trigger Event Detection During Gameplay

According to an aspect of the invention, once a gameplay session hascommenced, gameplay may be monitored in real-time for the detection of atrigger event (e.g., by trigger detection engine 128, or other gamelogic) that may cause the map to be dynamically modified (from itsinitial configuration) in order to improve the gameplay experience.

Examples of trigger events may include, but are not limited to, a changein a number of players in the gameplay session (e.g., the number ofplayers exceeds or falls below a predetermined threshold), a change in anumber of game players playing a particular player role (e.g., a numberof a certain type of player roles in a match exceeds or falls below apredetermined threshold), the pace or frequency of gameplayactions/events exceeding or falling below a predetermined threshold, thecommencement of a competition or newly available mission that takesplace in a map, an inference that one or more players are unhappy withthe current configuration of a map or otherwise would prefer variety(e.g., by monitoring unexpected attrition/rage quitting, or throughexplicit in-game voting or other feedback), or a change in othergameplay information, among other examples.

As a non-limiting example, matchmaking engine 122 may match one or moreplayers into a map being used in a current gameplay session. Theaddition of the one or more players may comprise the trigger event thatresults in the dynamic modification of the map.

According to an aspect of the invention, trigger events may besystem-defined (e.g., defined by the game logic) or user-defined (e.g.,through one or more user interfaces prior to the commencement of agameplay session). It should be appreciated that trigger events may bedifferent for different maps, different video games, and/or fordifferent maps utilized in the same video game. In some implementations,a collection of defined trigger events may be accessed and selectivelyapplied to individual maps. In other implementations, trigger events maybe created or customized for particular maps. Various configurations maybe implemented.

According to an aspect of the invention, when a trigger event isdetected during gameplay (e.g., by trigger detection engine 128, orother game logic), a map may be dynamically modified (from its initialconfiguration) as described in detail below. In some implementations,depending on the type of trigger event, detection of the trigger eventalone may be sufficient to dynamically modify the map. In otherimplementations, the gameplay event or action that produced (or resultedin) the triggering event must persist for a predetermined period of time(e.g., a modification waiting period) before the map is dynamicallymodified. This avoids changing the map frequently when near triggerthresholds, since players may find this confusing or disruptivedepending on the game or map design.

In some instances, two or more trigger events may occur during gameplay(and be detected) at substantially the same time. For example, both anumber of players and a number of player roles of a certain type mayexceed a predetermined threshold at substantially the same time. In suchan instance, either or both of the detected trigger events may result ina dynamic modification of the map. For example, in one implementation,the most significant trigger event, as defined by game logic or a user,may be used to dynamically modify a configuration of the map. In someimplementations, the occurrence of multiple trigger events may reducethe waiting period to dynamically modify the map. For example, if one ormore additional trigger events occur during the modification waitingperiod, the modification waiting period may be truncated. In otherimplementations, if two or more significant trigger events are detectedwithin a predetermined (e.g., short) period of time, the dynamic mapmodification may occur immediately without a modification waitingperiod. Other configurations may be implemented.

Dynamic Map Modification

According to an aspect of the invention, when trigger detection engine128 detects a trigger event, map management engine 130 may dynamicallymodify a configuration of the map to improve the gameplay experiencebased on the type of trigger event.

Dynamic modification of a map may comprise any one or more of thefollowing:

-   -   altering the boundary (or perimeter) of the map by, for example,        increasing or decreasing the boundary such that the boundary        respectively defines a larger or smaller area of playable space,        and/or opening up or closing (or otherwise altering) one or more        portions of the boundary;    -   altering the location, position, size, number, state, etc. of        one or more static map objects on the map;    -   altering the location, position, size, number, state, etc. of        one or more dynamic map objects on the map;    -   scaling the entire map by increasing or decreasing the size of        the map and its constituent objects (including any static map        objects, dynamic map objects, virtual characters or avatars        depicting players, etc.) to increase or decrease the area of        available space, respectively;    -   adding or removing non-player characters (NPCs) or other        artificial intelligence (AI) controlled avatars to the gameplay        experience;    -   combining all or a portion of the map with all or a portion of        one or more additional maps; and/or    -   modifying the attributes of existing map objects or terrain such        that player interaction is fundamentally impacted. Examples may        include making a river passable that was formerly impassable, or        converting molten lava into cooling rock that can now be        traversed without damaging a player's avatar. Regions of a map        may also be modified (e.g., filled with water, lava, quick-sand,        poisonous gas, poisonous swamps, etc.) to reduce or otherwise        alter the playable space of the map without altering the        boundary of the map.

As a result of the dynamic modification of the map, the map maytransform from its initial (or first or beginning) configuration to amodified (or new or second) configuration. Further, each detectedtrigger event that occurs during a gameplay session may cause mapmanagement engine 130 to dynamically modify a most recent (e.g, second)configuration of the map to a further modified (or new or third)configuration.

The following are illustrative and non-limiting examples of the variousways in which a map may be dynamically modified in real-time duringgameplay in response to certain trigger events.

Number of Players

In one implementation, a map be dynamically modified in real-time,during gameplay, based on a trigger event associated with a change in anumber of players in the gameplay session (e.g., the number of playersexceeds or falls below a predetermined threshold).

As one example, if a number of players during a gameplay session fallsbelow a predetermined number (e.g., a lower or first threshold), mapmanagement engine 130 may switch the state of one or more dynamic mapobjects (e.g., close a doorway, block a hallway, remove a bridge, etc.)of the map to selectively close off regions of the map, therebydecreasing the available playable space of the map. In this regard, theremaining players may be forced to play in a smaller area which may,depending on the nature of the game, increase encounters with otherplayers to foster more exciting action and gameplay. In someimplementations, when a region of a map is selectively closed off (orotherwise dynamically altered), player avatars may be transported out ofthe non-playable area to another area of the map (e.g., to a standardsafe spawn site). Alternatively, player avatars may be spawned elsewhereafter a death (or other game event), and the region of the map to beclosed may be closed once no more player avatars are in the region.

Conversely, if a number of players during a gameplay session exceeds apredetermined number (e.g., a higher or second threshold number), mapmanagement engine 130 may switch the state of one or more dynamic mapobjects (e.g., open a doorway, unblock a hallway, add/open a bridge,etc.) of the map to selectively open up additional regions of the map,thereby increasing the available playable space of the map.

An example is illustrated in FIGS. 4A-4C. In particular, FIG. 4A depictsa map 400A in an initial configuration for a gameplay session of amultiplayer video game involving 16 players. As shown, map 400Aincludes, as playable space, regions A and B as dynamic map objects 408are in an open state.

During gameplay, upon detection that the number of players in thegameplay session has decreased from 16 players to a number equal to orbelow a first (or lower) pre-determined threshold number (e.g., 8players), map management engine 130 may, as a result of the triggeringevent, switch dynamic map objects 408 to a closed state (or remove themaltogether), thereby reducing the available playable space of the map tocomprise only Region B as shown in map 400B of FIG. 4B (in a secondconfiguration of the map).

By contrast, during gameplay, upon detection that the number of playersin the gameplay session has increased from 16 players to a number equalto or above a second (or upper) pre-determined threshold number (e.g.,20 players), map management engine 130 may, as a result of thetriggering event, switch dynamic map objects 408 to an open state(and/or add new dynamic map objects), thereby increasing the availableplayable space of the map to comprise Regions A, B, and C as shown inmap 400C of FIG. 4C (in a second configuration of the map).

In this regard, the map may by dynamically modified in real-time duringa gameplay session such that various configurations of the map (such asthose illustrated in FIGS. 4A, 4B, & 4C) may be made available toplayers based on trigger events that occur during gameplay.

In one implementation, the gameplay session (which players may join orleave in progress) may comprise an unbounded gameplay session such asthat disclosed in co-pending, and concurrently filed, U.S. patentapplication Ser. No. 14/712,387, entitled “System and Method forProviding Continuous Gameplay in a Multiplayer Video Game Through anUnbounded Gameplay Session”, which is hereby incorporated by referenceherein in its entirety.

Types of Player Roles

In one implementation, a map may be dynamically modified in real-time,during gameplay, based on a trigger event associated with a change in anumber of game players playing a particular player role. Player rolesmay, of course, differ based on the particular video game.

As a non-limiting example, a player role in a First-Person-Shooter gamemay comprise that of a sniper. During a gameplay session, if a number ofplayers in the sniper role decreases to a number equal to or below afirst (or lower) pre-determined threshold number, map management engine130 may, as a result of the triggering event, add or provide ladders to(newly added or existing) sniper perches to the map or improvelong-distance sight lines by removing occluding objects in order toincentivize players switch to a sniper role to provide more balancedgameplay. In another example, the map may shrink or remove variousmap-based sniper advantages based on an inference that current playersfavor close-quarters gameplay.

By contrast, if a number of players in the sniper role increases duringa gameplay session to a number equal to or above a second (or higher)pre-determined threshold number, map management engine 130 may, as aresult of the triggering event, remove ladders and/or remove sniperperches and/or add occluding objects which reduce sight lines from themap in order to deter players from selecting the sniper role.

The types of static and/or dynamic map objects that may be added to orremoved from (or be otherwise altered on) a map may differ based on thetype and nature of various player roles in various video games.

Pace or Frequency of Gameplay Actions/Events

In one implementation, a map may be dynamically modified in real-time,during gameplay, based on a trigger event associated with the pace orfrequency of certain gameplay actions or events.

Returning back to the non-limiting example of a First-Person-Shootergame, excitement during gameplay may, for example, be based on thefrequency of the occurrence of a particular event such as a firefight.As such, during a gameplay session, if the frequency of firefightsdecreases to a value equal to or below a first (or lower) pre-determinedthreshold value, map management engine 130 may, as a result of thetriggering event, alter the area of playable space on the map byaltering one or more of the map's boundary, static map object(s), and/ordynamic map object(s) to provide more opportunities for firefights andincrease the pace of play.

By contrast, if the frequency of firefights increases during a gameplaysession to a value equal to or above a second (or upper) pre-determinedthreshold value, map management engine 130 may, as a result of thetriggering event, alter the area of playable space on the map byaltering one or more of the map's boundary, static map object(s), and/ordynamic map object(s) to reduce the number of firefights and slow downthe pace of play.

The various types of game actions or events that may be used as atriggering event may, of course, differ based on the particular videogame.

Gameplay State Information

In addition to the foregoing examples, a map may be dynamically modifiedin real-time, during gameplay, based on a trigger event associated withchanges in other gameplay state information including, withoutlimitation, types of matches (e.g., team death match, capture the flag,etc.), elapsed time or remaining time in a gameplay session, and/orother information related to a gameplay session. For example, in someimplementations, if the elapsed time of a gameplay session reaches apredetermined threshold, a map may be dynamically modified in any one ormore of the manners described herein for variety. Numerousconfigurations may be implemented.

Exemplary Flowchart

FIG. 5 depicts an exemplary flowchart 500 of processing operations forproviding dynamically variable maps in a video game, according to anaspect of the invention. The various processing operations and/or dataflows depicted in FIG. 5 are described in greater detail herein. Thedescribed operations may be accomplished using some or all of the systemcomponents described in detail above and, in some implementations,various operations may be performed in different sequences and variousoperations may be omitted. Additional operations may be performed alongwith some or all of the operations shown in the depicted flow diagrams.One or more operations may be performed simultaneously. Accordingly, theoperations as illustrated (and described in greater detail below) areexemplary by nature and, as such, should not be viewed as limiting.

In an operation 502, one or more trigger events may be defined. Triggerevents may be system-defined (e.g., defined by the game logic) oruser-defined (e.g., through one or more user interfaces prior to thecommencement of a gameplay session). It should be appreciated thattrigger events may be different for different maps, different videogames, and/or for different maps utilized in the same video game.Examples of trigger events may include, but are not limited to, a changein a number of players in the gameplay session (e.g., the number ofplayers exceeds or falls below a predetermined threshold), a change in anumber of game players playing a particular player role (e.g., a numberof a certain type of player roles in a match exceeds or falls below apredetermined threshold), the pace or frequency of gameplayactions/events exceeding or falling below a predetermined threshold, thecommencement of a competition or newly available mission that takesplace in a map, an inference that one or more players are unhappy withthe current configuration of a map or otherwise would prefer variety(e.g., by monitoring unexpected attrition/rage quitting, or throughexplicit in-game voting or other feedback), or a change in othergameplay information, among other examples.

In an operation 504, one or more players, such as players whose in-gameavatars are waiting in a virtual game lobby to join a gameplay session,may be matched. In one implementation, a matching engine may use knownor hereafter-developed matchmaking techniques to generate a match bygrouping players in an effort to produce the most satisfying playerexperiences. Game profiles, player profiles, match variables, and otherfactors may be considered when generating matches.

In an operation 506, a map selection engine may select, generate, orotherwise obtain a map for a match of a gameplay session. In someimplementations, one or more maps may be selected and retrieved fromamong a collection of pre-generated maps stored, for instance, in one ormore databases. Alternatively, the map selection engine may generate oneor more maps, or dynamically modify one or more existing maps, inreal-time (“on the fly”) for a gameplay session to change the playablespace by altering one or more of the map's boundary, static mapobject(s), and/or dynamic map object(s).

In some implementations, a map (whether selected, generated, ormodified) may have an initial (or first or beginning) configurationbased on gameplay session information. Gameplay session information maydescribe various game characteristics of a gameplay session that mayinfluence the quality of gameplay. For example, gameplay sessioninformation may include, without limitation, a number of players, acomposition of teams (e.g., number and/or types of roles in each team),duration of gameplay (e.g., how long a given gameplay session isexpected to last), types of matches (e.g., team death match, capture theflag, etc.), and/or other information related to a gameplay session. Inanother implementation, a map may be selected for a match randomly.

In yet other implementations, one or more players may select the map tobe played in a match of the gameplay session. For instance, before thestart of a match, one or more players may vote on the map to be usedduring the gameplay session.

In an operation 508, a gameplay session may commence. The gameplaysession may comprise any type of gameplay session including, withoutlimitation, a real gameplay session and/or a practice gameplay session(e.g., associated with a “practice” or “training” mode of a game).

In an operation 510, gameplay may be monitored in real-time for thedetection of a trigger event (e.g., by a trigger detection engine, orother game logic).

If no trigger event is detected in operation 510, a determination may bemade as to whether the gameplay session should continue. If so,processing may resume at operation 508. If not, the gameplay session mayterminate in an operation 516.

If a trigger event is detected in operation 510, the map (provided inoperation 506) may be dynamically modified (from its initialconfiguration) in an operation 512.

In operation 512, a map management engine may dynamically modify aconfiguration of the map to improve the gameplay experience based on thetype of trigger event. Dynamic modification of a map may comprise anyone or more of: altering the boundary (or perimeter) of the map by, forexample, increasing or decreasing the boundary such that the boundaryrespectively defines a larger or smaller area of playable space, and/oropening up or closing (or otherwise altering) one or more portions ofthe boundary; altering the location, position, size, number, state, etc.of one or more static map objects on the map; altering the location,position, size, number, state, etc. of one or more dynamic map objectson the map; scaling the entire map by increasing or decreasing the sizeof the map and its constituent objects (including any static mapobjects, dynamic map objects, virtual characters or avatars depictingplayers, etc.) to increase or decrease the area of available space,respectively; adding or removing non-player characters (NPC) or otherartificial intelligence (AI) controlled avatars to the gameplayexperience; combining all or a portion of the map with all or a portionof one or more additional maps; and/or modifying the attributes ofexisting map objects or terrain such that player interaction isfundamentally impacted.

As a result of the dynamic modification of the map, the map maytransform from its initial (or first or beginning) configuration to amodified (or new or second) configuration. Gameplay may then continue inoperation 508.

Other implementations, uses and advantages of the invention will beapparent to those skilled in the art from consideration of thespecification and practice of the invention disclosed herein. Thespecification should be considered exemplary only, and the scope of theinvention is accordingly intended to be limited only by the followingclaims.

What is claimed is:
 1. A computer-implemented method of providing adynamically variable map in a video game, the method being implementedin a host computer system having one or more physical processorsprogrammed with computer program instructions that, when executed by theone or more physical processors, cause the host computer system toperform the method, the method comprising: obtaining, by the hostcomputer system, a map for use in a gameplay session, the map defining aplayable space available to one or more players participating in thegameplay session; detecting, by the host computer system, an occurrenceof a trigger event during the gameplay session; and dynamicallymodifying, by the host computer system, one or more attributes of themap during the gameplay session, responsive to detection of the triggerevent, to alter the available playable space of the map.
 2. The methodof claim 1, wherein the trigger event comprises a total number ofplayers in the gameplay session falling below a predetermined threshold,the method further comprising: dynamically modifying the one or moreattributes of the map during the gameplay session to decrease theavailable playable space of the map.
 3. The method of claim 1, whereinthe trigger event comprises a total number of players playing aparticular role in the gameplay session exceeding a predeterminedthreshold, the method further comprising: altering one or more staticmap objects or dynamic map objects of the map during the gameplaysession to make gameplay more challenging for the particular role. 4.The method of claim 1, wherein the trigger event comprises a totalnumber of players playing a particular role in the gameplay sessionfalling below a predetermined threshold, the method further comprising:altering one or more static map objects or dynamic map objects of themap during the gameplay session to make gameplay easier for theparticular role.
 5. The method of claim 1, wherein the trigger eventcomprises a frequency of an occurrence of a particular game event in thegameplay session exceeding a predetermined threshold, the method furthercomprising: dynamically modifying the one or more attributes of the mapduring the gameplay session to make the occurrence of the particulargame event more challenging in the gameplay session so as to reduce thefrequency of the occurrence of the particular game event.
 6. The methodof claim 1, wherein the trigger event comprises a frequency of anoccurrence of a particular game event in the gameplay session fallingbelow a predetermined threshold, the method further comprising:dynamically modifying the one or more attributes of the map during thegameplay session to make the occurrence of the particular game eventmore likely in the gameplay session so as to increase the frequency ofthe occurrence of the particular game event.
 7. A system for providing adynamically variable map in a video game, the system comprising: a hostcomputer system comprising one or more physical processors programmedwith one or more computer program instructions which, when executed,programs the host computer system to: obtain a map for use in a gameplaysession, the map defining a playable space available to one or moreplayers participating in the gameplay session; detect an occurrence of atrigger event during the gameplay session; and dynamically modify one ormore attributes of the map during the gameplay session, responsive todetection of the trigger event, to alter the available playable space ofthe map.
 8. The system of claim 7, wherein the trigger event comprises atotal number of players in the gameplay session falling below apredetermined threshold, and wherein the host computer system is furtherprogrammed to: dynamically modify the one or more attributes of the mapduring the gameplay session to decrease the available playable space ofthe map.
 9. The system of claim 7, wherein the trigger event comprises atotal number of players playing a particular role in the gameplaysession exceeding a predetermined threshold, and wherein the hostcomputer system is further programmed to: alter one or more static mapobjects or dynamic map objects of the map during the gameplay session tomake gameplay more challenging for the particular role.
 10. The systemof claim 7, wherein the trigger event comprises a total number ofplayers playing a particular role in the gameplay session falling belowa predetermined threshold, and wherein the host computer system isfurther programmed to: alter one or more static map objects or dynamicmap objects of the map during the gameplay session to make gameplayeasier for the particular role.
 11. The system of claim 7, wherein thetrigger event comprises a frequency of an occurrence of a particulargame event in the gameplay session exceeding a predetermined threshold,and wherein the host computer system is further programmed to:dynamically modify the one or more attributes of the map during thegameplay session to make the occurrence of the particular game eventmore challenging in the gameplay session so as to reduce the frequencyof the occurrence of the particular game event.
 12. The system of claim7, wherein the trigger event comprises a frequency of an occurrence of aparticular game event in the gameplay session falling below apredetermined threshold, and wherein the host computer system is furtherprogrammed to: dynamically modify the one or more attributes of the mapduring the gameplay session to make the occurrence of the particulargame event more likely in the gameplay session so as to increase thefrequency of the occurrence of the particular game event.